Method and system for enhancing live stream delivery quality using prebursting

ABSTRACT

The subject matter herein relates to a method to “accelerate” the delivery of a portion of a data stream across nodes of a stream transport network. A portion of a live stream is forwarded from a first node to a second node in a transport network at a high bitrate as compared to the stream&#39;s encoded bitrate, and thereafter, the stream continues to be forwarded from the first node to the second node at or near the encoded bitrate. The disclosed technique of forwarding a portion of a stream at a high bitrate as compared to the encoded bitrate of the stream is sometimes referred to as “prebursting” the stream. This technique provides significant advantages in that it reduces stream startup time, reduces unrecoverable stream packet loss, and reduces stream rebuffers as the stream is viewed by a requesting end user that has been mapped to a media server in a distributed computer network such as a content delivery network.

This application is a continuation of Ser. No. 10/410,986, filed Apr.10, 2003, now U.S. Pat. No. 7,409,456, which application was based onand claimed priority to Ser. No. 60/371,463, filed Apr. 10, 2002.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to high-performance,fault-tolerant streaming media delivery in a content delivery network(CDN).

2. Description of the Related Art

Streaming media is a type of Internet content that has the importantcharacteristic of being able to be played while still in the process ofbeing downloaded. A client can play the first packet of the stream, anddecompress the second, while receiving the third. Thus, an end user canstart enjoying the multimedia without waiting to the end oftransmission. Streaming is very useful for delivering media becausemedia files tend to be large, particularly as the duration of theprogramming increases. Indeed, for live events, the file size is, ineffect, infinite. To view a media file that is not streamed, users mustfirst download the file to a local hard disk—which may take minutes oreven hours—and then open the file with player software that iscompatible with the file format. To view streaming media, the user'sbrowser opens player software, which buffers the file for a few secondsand then plays the file while simultaneously downloading it. Unlikesoftware downloads, streaming media files are not stored locally on auser's hard disk. Once the bits representing content are used, theplayer typically discards them.

Streaming media quality varies widely according to the type of mediabeing delivered, the speed of the user's Internet connection, networkconditions, the bit rate at which the content is encoded, and the formatused. In general, streaming audio can be FM quality, but, given typicalbandwidth constraints, streaming video is poor by TV standards, withsmaller screens, lower resolution, and fewer frames per second. Thesource for streaming media can be just about any form of media,including VHS or Beta format tapes, audio cassettes, DAT, MPEG video,MP3 audio, AVI, and the like. Prior to streaming, the content must firstbe encoded, a process which accomplishes four things: conversion of thecontent from analog to digital form, if necessary; creation of a file inthe format recognized by the streaming media server and player;compression of the file to maximize the richness of the content that canbe delivered in real-time given limited bandwidth; and, establishing thebit rate at which the media is to be delivered. Content owners typicallychoose to encode media at multiple rates so that users with fastconnections get as good an experience as possible but users with slowconnections can also access the content.

Non-streaming content is standards-based in the sense that the serverand client software developed by different vendors, such as Apacheserver, Microsoft Internet Explorer, Netscape Navigator, and the like,generally work well together. Streaming media, however, usually relieson proprietary server and client software. The server, client,production and encoding tools developed by a streaming software vendorare collectively referred to as a format. Streaming media encoded in aparticular format must be served by that format's media server andreplayed by that format's client. Streaming media clients are oftencalled players, and typically they exist as plug-ins to Web browsers.Streaming media clients are also often capable of playingstandards-based non-streaming media files, such as WAV or AVI. The threemajor streaming media formats in use today are: RealNetworks RealSystemG2, Microsoft Windows Media Technologies (“WMT”), and Apple QuickTime.RealSystem G2 handles all media types including audio, video, animation,and still images and text. RealSystem G2 and QuickTime support SMIL, anXML-based language that allows the content provider to time and positionmedia within the player window. To deliver the media in real time Realand QuickTime use RTSP.

It is well-known to deliver streaming media using a content deliverynetwork (CDN). A CDN is a network of geographically distributed contentdelivery nodes that are arranged for efficient delivery of digitalcontent (e.g., Web content, streaming media and applications) on behalfof third party content providers. Typically, a CDN is implemented as acombination of a content delivery infrastructure, a DNS-basedrequest-routing mechanism, and a distribution infrastructure. Thecontent delivery infrastructure usually comprises a set of “surrogate”origin servers that are located at strategic locations (e.g., Internetnetwork access points, Internet Points of Presence, and the like) fordelivering copies of content to requesting end users. Therequest-routing mechanism allocates servers in the content deliveryinfrastructure to requesting clients in a way that, for web contentdelivery, minimizes a given client's response time and, for streamingmedia delivery, provides for the highest quality. The distributioninfrastructure consists of on-demand or push-based mechanisms that movecontent from the origin server to the surrogates. In live streaming, theorigin server may include an encoder. An effective CDN servesfrequently-accessed content from a surrogate that is optimal for a givenrequesting client. In a typical CDN, a single service provider operatesthe request-routers, the surrogates, and the content servers. Inaddition, that service provider establishes business relationships withcontent publishers and acts on behalf of their origin server sites toprovide a distributed delivery system. A well-known commercial CDNservice that provides web content and media streaming is provided byAkamai Technologies, Inc. of Cambridge, Mass.

As described in U.S. Pat. No. 6,665,726, which is incorporated herein byreference, live streaming can be further enhanced by having the CDN sendmultiple copies of the same stream over different routes from a CDNentry point to the optimal streaming server at the edge of the Internet.These copies are then combined to form one complete, original-qualitystream, which is sent from the streaming server to the end users. FIG. 1illustrates this process in more detail. A broadcast stream 100 is sentto a CDN entry point 102. An entry point, for example, typicallycomprises two servers (for redundancy), and each server can handle manystreams from multiple content providers. Once the entry point receivesthe stream, it rebroadcasts copies of the stream to so-called reflectors104 a-n. The streams preferably are multiplexed and delivered to the setreflectors preferably via UDP (e.g., WMT encapsulated in UDP over IP).These reflectors are preferably diverse from a network and geographicstandpoint (e.g., at diverse Internet backbone data centers) to ensurefault tolerance. Each reflector, in turn, rebroadcasts its copy of thestream to each subscribing region, e.g., region 106 d, of a set ofregions 106 a-n. A subscribing region 106 d typically is a CDN regionthat contains one or more streaming edge nodes 108 a-n to which user(s)have been routed by the CDN DNS-based request-routing mechanism. Inother words, set reflectors send their streams to every edge regionwhere they are needed. A CDN region, in this example, includes a set ofedge nodes connected by a common backbone 109, e.g., a local areanetwork (LAN). Typically, an edge node, e.g., node 108 d, comprises astreaming server 112 and it may include a cache 110. A representativeserver runs an Intel processor, the Linux operating system and a RealMedia or QuickTime Server. For Windows-based platforms, a representativeserver runs an Intel processor, Windows NT or 2000, and a Windows MediaServer.

The reflector network is used within a content delivery network toenable requesting end users to subscribe to live streams that have beenpublished to CDN entry points. A reflector typically is a generalizedpacket router program. The reflector network preferably comprises ahierarchy of reflectors that are located at the various entry pointsinto the CDN, at each edge node at which requesting users may bedirected by the CDN to obtain live streams, and at various “reflector”nodes located within at least one intermediate layer (in the hierarchy)between the entry points and the edge nodes. As described in U.S. Pat.No. 6,751,673, the edge nodes and each reflector node may also include amanager program that arranges for feeds. When an end user is directed toan edge node that is not yet receiving the desired stream, the edgenode's manager issues a subscription request to a set of reflectornodes. If the reflector node(s) are already receiving the desiredstream, their reflector(s) begin sending it to the requesting edge node.If, however, the reflector node(s) are not already receiving the desiredstream, their manager programs issue the subscription request to theentry point(s) to start the feed. In such a live transport network, theentrypoint announces the existence of a stream to reflectors, while edgereflectors in a given region subscribe for the stream. The reflectorspropagate this subscription to the entrypoint, receive the data, andpropagate the data to the edge reflectors, who then send it to mediaservers over a backend network.

From April 2001 to April 2002, the number of high-speed, home-basedInternet users in the United States grew from 15.9 million to 25.2million individuals. Even with low-cost, high-speed Internetconnections, delivering streaming media to end users is difficult. Dueto widely acknowledged Internet bottlenecks, many consumers are forcedto endure slow and unreliable startup of audio and video streams,periods during which significant rebuffering interrupts the experience,or degraded quality of delivery that leads to choppy “slide-show”quality instead of smooth video. Unfortunately, for content providers,site visitors do not find such experiences compelling and, thus,streaming media production dollars often are wasted while importantbranding and product messages never reach their intended audience.

Therefore, for customers seeking an optimal return on their streamingmedia investment, it is important that end users attempting to view orlisten to a stream have a high quality experience—one that delivers thecontent as well as entices the user to return to the site.

It would be desirable to provide techniques for enhancing the end userquality of media streams. The present invention addresses this problem.

BRIEF SUMMARY

The subject matter herein relates generally to improving how a live datastream is delivered between network nodes in a distributed computingnetwork, such as a content delivery network (CDN).

It is a general object of the invention to enhance how a live streamingtransport network is used in a content delivery network.

It is a more general object of the invention to enhance the quality ofan end user's perception of a media stream such as an audio or videofile that is delivered over a computer network.

It is a more specific object of the invention to “accelerate” thedelivery of a portion of a data stream across nodes of a streamtransport network. According to the invention, a portion of a livestream is forwarded from a first node to a second node in a transportnetwork at a high bitrate as compared to the stream's encoded bitrate,and thereafter, the stream continues to be forwarded from the first nodeto the second node at or near the encoded bitrate. The disclosedtechnique of forwarding a portion of a stream at a high bitrate ascompared to the encoded bitrate of the stream is sometimes referred toas “prebursting” the stream. This technique provides significantadvantages in that it reduces stream startup time, reduces stream packetloss, and reduces stream rebuffers as the stream is viewed by arequesting end user that has been mapped to a media server in adistributed computer network such as a content delivery network

In an illustrated embodiment, each node in a live streaming transportnetwork retains a history (e.g., “n” seconds of the stream, or “b” bytesof data of the stream, which amount is configurable) of every streamthat passes through the node. Preferably, the node stores a history forevery stream to which it is subscribed if a subscription-based system isbeing employed in the transport network. This history preferably isstored in a buffer, memory, cache, disk or other suitable datastore.When the node receives a request (e.g., a subscription request) for thestream from another node, the first node forwards the history to therequesting node at a bitrate that is higher (e.g., 8.times., whichamount is configurable) than the bitrate x of the stream. After theburst, the node continues to forward the stream to the requesting nodeas and when new packets are received, typically at the normal bitratefor the stream. As noted, how much of the stream is buffered at a givennode and how fast to burst the history are configurable, and theseattributes may be set on a per stream basis, on a portset (a collectionof streams) basis, on a per node basis, or on a per streaming mediaformat basis.

The foregoing has outlined some of the more pertinent features of thepresent invention. These features should be construed to be merelyillustrative. Many other beneficial results can be attained by applyingthe disclosed invention in a different manner or by modifying theinvention as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference should be made to the following DetailedDescription taken in connection with the accompanying drawings, inwhich:

FIG. 1 is a block diagram of a known content delivery network in whichthe present invention may be implemented;

FIG. 2 illustrates a live streaming network without preburstingaccording to the present invention;

FIG. 3 is a simplified flowchart illustrating the buffering and burstingtechnique of the present invention;

FIG. 4 illustrates a live streaming network with prebursting accordingto the present invention;

FIG. 5 is a graph illustrating how prebursting reduces stream startuptime; and

FIG. 6 is a graph illustrating how prebursting reduces streamrebuffering.

DETAILED DESCRIPTION

The present invention describes a technique referred to as“prebursting,” which is a feature of live streaming content deliverythat drastically improves the quality of streams delivered to the enduser. For background, the following describes how a live streaming CDNwould work without prebursting. Thereafter, a description of preburstingis provided, illustrating how and why this functionality leads to betterstream quality and performance for the end-user.

By way of background, this invention preferably is implemented in a livestreaming transport network of a content delivery network. This is not alimitation of the invention, however. In one embodiment, the transportnetwork is a “reflector” network to enable requesting end users tosubscribe to live streams that have been published to CDN entry points.A reflector is a generalized packet router program. The reflectornetwork preferably comprises a hierarchy of reflectors: at least onereflector located at each entry point to the CDN, at each edge node atwhich requesting users may be directed by the CDN to obtain livestreams, and at various “reflector” nodes located within at least oneintermediate layer (in the hierarchy) between the entry points and theedge nodes. The intermediate layer is useful to facilitate delivery ofstreams for which there is high demand. The edge nodes and eachreflector node also include a manager program that arranges for feeds.When an end user is directed to an edge node that is not yet receivingthe desired stream, the edge node's manager issues a subscriptionrequest to a set of reflector nodes. If the reflector node(s) arealready receiving the desired stream, their reflector(s) begin sendingit to the requesting edge node. If, however, the reflector node(s) arenot already receiving the desired stream, their manager programs issuethe subscription request up the hierarchy, ultimately reaching the entrypoint(s) to start the feed. In this illustrative live transport network,the entrypoint announces the existence of a stream to reflectors, whileedge reflectors in a given region subscribe for the stream. Thereflectors propagate this subscription to the entrypoint, receive thedata, and propagate the data to the edge reflectors, who then send it tomedia servers over a backend network.

The following is provided with reference to FIG. 2. This is adescription of how a live content delivery network such as describedabove works without prebursting. In this illustrative example, it isassumed that that the set reflectors are not already subscribed to thestream requested by the end-user. The subscription technique isdescribed above generally and in U.S. Pat. No. 6,751,673, which issummarized below:

Step (1): An end user's media player 200 requests the stream from anedge server 202.

Step (2): The edge server 202 asks a leader process 204 in the region206 for the stream, and one or more leaders ask their respective setreflector 208 for the stream by sending subscription messages up thenetwork.

Step (3): The set reflector 208 sends a subscription message up to theentry point 210 for the stream.

Step (4): The entry point 210 sends the stream to the set reflector 208,which forwards the packets as it receives them from the encoder.

Steps (5) and (6): The set reflector 208 forwards the stream packets tothe leader process 204 of the edge region 206, and the leader forwardsthem to the edge server 202 on a backend (e.g., LAN) 212, and the serversends the packet to the media player 200 of the end-user. After themedia player receives a certain critical amount of data, it starts toplay the stream.

The forwarding of the packets in steps (4)-(6) is done when the packetsare received; therefore, typically the packets are sent from the entrypoint 210 to the edge servers at the encoded bitrate of the stream. Notethat the steps differ from the above if the particular set reflector 208(in this example) is already subscribed to the stream. In such case, thesubscription process stops at the set reflector and need not be sent upto the entry point.

FIG. 3 illustrates the use of “prebursting” according to the presentinvention.

FIG. 3 is a flowchart of the process at a high level. Generally,prebursting refers to the forwarding of a given first portion (a“history”) of a requested data stream from a first node to a second nodeat a first bitrate, and then the subsequent forwarding of a given secondportion of the requested data stream from the first node to the secondat a second bitrate. The first bitrate typically is much higher than theencoded bitrate of the stream and, thus, is sometimes deemed to be a“burst,” thereby giving rise to the term prebursting to describe theinventive technique. Thus, as seen in FIG. 3, a given node stores a“history” of a given stream, i.e., a given portion (usually measured in“t” seconds worth of stream data). This is step 300. Of course, one ofordinary skill in the art will appreciate that the amount of the streamthat is buffered in the node can be measured in other than a temporalmanner, e.g., such as storing “b” bytes of data. Thus, a “history” of“t” seconds is equivalent to a history of “b” bytes that would berendered over such “t” seconds. At step 302, a test is made to determineif a request for the given stream has been received at the given node.If not, the routine cycles. Upon receiving a request, at step 304, thegiven stream “bursts” the history to the requesting node at a highbitrate and then, at step 306, the first node continues to forward aremainder of the stream at or near the encoded bitrate. An importantobservation underlying prebursting is that to achieve high streamquality, it is generally insufficient to just forward packets throughthe network (i.e., from a first node to a second node) at the rate atwhich they are being received, i.e., it is not sufficient to alwaystransmit packets at the encoded bitrate. Rather, according to theinvention, it helps a great deal to burst some of the data at a ratemuch higher than the encoded bitrate of the stream.

With reference to FIG. 4, prebursting achieves the following behavior.When an end user 400 requests a stream, the content delivery networkprovides a short burst of data (for example, twenty (20) seconds worthof stream data) to the media player, at a high data rate (for example,eight (8) times the encoded bitrate of the stream). The remainder of thestream packets following the burst then are sent as and when they arereceived, i.e., at the encoded bitrate. For instance, for a 100 Kbpsstream, perhaps the first 20 seconds worth of data, i.e., 20.times.100Kbits=250 Mbytes of data, would be streamed to the edge and eventuallyto the end-user at a burst rate of 800 Kbps (=100K times 8), while therest of the stream is continued to be streamed at the encoded bitrateof, say, 100 Kbps.

As seen in FIG. 4, which is merely representative, prebursting may beeffected at any given node of the transport network. The steps of FIG. 4correspond to the steps described above and illustrated in FIG. 2.Typically, every node in the transport network retains a preburstingbuffer to store a “history” for every stream that goes through the node.Entry point 410 includes one or more buffers 414 a-n, and set reflector408 includes one or more buffers 416 a-n, for this purpose. The size ofa given buffer preferably is configurable on a per-stream, per-portset,per-node or per-media format basis, to maximize performance. Preferably,each node includes the capability to buffer a given stream, but this isnot a requirement of the invention. It may be desirable to enableprebursting in different portions of the transport network, such asbetween an entry point and a set reflector, between an intermediate setreflector and an edge region, or between edge servers in a given edgeregion, or any combination. More generally, the present inventionenvisions the use of the prebursting technique between any first andsecond nodes of a streaming transport network, and the first and secondnodes may comprise any given hardware, operating system, packetforwarding engine, streaming media server, or media player. Thus, theinventive technique may be carried out between a media server (the firstnode) and a given end user machine running a web browser and mediaplayer plug-in (the second node), although typically the invention willbe implemented across transport nodes in the CDN.

Prebursting in this manner typically results in drastic improvements inthe quality of the stream delivered to the end-user. Thus, for example,assume stream quality is measured using several different metrics, e.g.:(a) failure percent, or how often the stream failed to start and play;(b) startup time, or how quickly the stream started to play after theuser hits the “play” button; (c) thinning and loss percentage, or whatfraction of the information was thinned at the server or lost in transitto the end-user resulting in degradation in what the user sees (e.g.,slide show-like presentations); and (d) rebuffering, or how often andhow long did the playback freeze because the media player did not haveinformation in its buffer to continue the play. Prebursting cansignificantly improve at least several of these metrics as outlinedbelow.

The startup time for the streams decrease significantly because theinitial information needed by the media player to start the stream istransmitted through the network and to the media player at a much morerapid rate. This is illustrated in the graph of FIG. 5.

There is less thinning and loss in the playback when prebursting is usedbecause there is more loss recovery. Prebursting enables the mediaplayer to buffer several seconds of data ahead of what is currentlybeing played-back to the end-user.

Therefore, the media player has more time to recover a missing packet.Thus, for example, if the media player is able to buffer the packets tobe played back at t+15 seconds at time t, then it has roughly 15 secondsto recover a missing packet because the missing packet would not beneeded for playback for 15 more seconds.

There are fewer incidents of rebuffering due to prebursting for similarreasons.

Because prebursting enables the media player to buffer several secondsof data ahead of what is being played-back, it is much less likely thatthe media player would run out of data causing it to interrupt theplayback. This is illustrated in FIG. 6.

The performance enhancements due to prebursting vary from stream tostream and from one format to another. For instance, for WMS,experimental results have shown a factor 2.9 improvement in startuptimes for some streams (from 18.7 seconds without prebursting to 6.3seconds with prebursting). This is illustrated in the graph of FIG. 5,which illustrate how a stream startup time changed from about 12 secondsto 7 seconds once prebursting was employed. For some Real streams,experimental results have shown rebuffer frequency down drastically byfactors of 20 or so, and startup times reduced by 3 seconds. This isillustrated in the graph of FIG. 6.

The following is a brief description of how the live content deliverynetwork works with prebursting. As used herein, the generic term “node”typically denotes an entry point, a set reflector, or a leader/edgeserver in the edge region. According to one embodiment, each node in thenetwork stores preburst buffer-size=X seconds worth of history of everystream to which it is currently subscribed. That is, at time t, the nodestores packets for the stream from time t-X to t in its preburst buffer.When a node A sends up a subscription request for a stream to node B,node B sends to node A its history of X seconds of the stream that iscurrently stored in its preburst buffer. The history is sent at a rateof preburst_factor=Y times the encoded bitrate of the stream. Of course,Y need not be an integer or exact multiple of the encoded bitrate. Afterthe history is sent, node B will continue to send packets for the streamto node A at the rate at which it is receiving them, i.e., at theencoded bitrate of the stream. Preferably, both preburst_size andpreburst_rate are configurable parameters and can be tuned depending onthe format (WMS, Real, Quicktime), stream properties (encoded bitrate,audio versus video, and so forth) to maximize the stream quality of theend-user.

FIG. 4 illustrates an embodiment of the live stream delivery withprebursting. For simplicity, assume that the set reflectors 408 are notsubscribed to the stream requested by the end-user, and so thesubscription travels up to the entry point 410.

Step (1): The end user's media player 400 requests the stream from anedge server 402.

Step (2): The edge server 402 asks the leader process 404 in the region406 for the stream, and one or more leaders ask their respective setreflectors 408 for the stream by sending a subscription message up thenetwork.

Step (3): The set reflector 408 sends a subscription message up to theentry point 410 for the stream.

Step (4): The entry point 410 (in this example) bursts its storedhistory for the stream (from a buffer 414) to the set reflector 408.Then, the set reflector 408 continues to forward the packets as itreceives them from the encoder (i.e., at the encoded bitrate).

Steps (5) and (6): The set reflector 408 forwards the stream to theleader 404 of the edge region 406, and the leader forwards to the edgeserver 402 on a backend network 412 (a LAN connecting the edge serversin a region), and the server 402 sends the packet to the media player onthe end-user client machine. The packets are forwarded as and when theyare received. After the media player receives a certain amount of data,it starts to play the stream.

Note that in the above instance the preburst happens only once, in thiscase at the entry point, and the nodes downstream from the entry pointjust forward the packets at the rate they receive them. More generally,because downstream nodes forward packets at the rates received, it istypically only necessary to preburst at just one point along the streamtransport path. Thus, if there are three serial nodes, node A, node Band node C, a preburst implemented at node A generates packets that nodeB's packet forwarding engine will end up delivering to node C in apreburst manner, and this is the case even though node B is notbuffering for this purpose. In the example, the prebursted data travelsat an accelerated rate to the edge and gets streamed to the end user sothat the user receives the ultimate benefit of the upstream preburst.

In the case where the set reflector 408 is already subscribed to, theprocessing is similar to the above, except that the subscription processstops at the set reflector, and the set reflector (instead of the entrypoint) sends down a burst of packets from its preburst buffer 416 to thesubscribing edge region. In the remaining case, where the leaders aresubscribed to the stream but the edge server is not, the leader process404 preferably prebursts to the edge server from its preburst buffer 418on the region back-end network.

Although not required, an application (e.g., a set reflector, a leaderprocess, or the like) that is already receiving data may ignore preburstdata as duplicates, while one that is waiting for a preburst may ignoreregular packets until the preburst packet sequence numbers “catch up”with the regular packets or a specified timeout (e.g., 2 seconds) passeswith no preburst data arriving.

A representative subscription mechanism is described in U.S. Pat. No.6,751,673, and incorporated herein by reference. There is no requirementthat the present invention be used in the context of a subscriptionmechanism, of course.

Many of the functions described above have been described andillustrated as discrete programs. One of ordinary skill will appreciatethat any given function, alternatively, may comprise part of anotherprogram. Thus, any reference herein to a program should be broadlyconstrued to refer to a program, a process, an execution thread, orother such programming construct. As a concrete example, the programsreferred to above may run as separate threads within a larger program.Generalizing, each function described above may be implemented ascomputer code, namely, as a set of computer instructions, for performingthe functionality described via execution of that code usingconventional means, e.g., a processor, a machine, a set of connectedmachines, a system, or the like.

This technique provides significant advantages in that it reduces streamstartup time, and it reduces stream rebuffers as the stream is viewed bya requesting end user that has been mapped to a media server in adistributed computer network such as a content delivery network. Inaddition, prebursting reduces unrecoverable stream packet loss byaffording nodes in the transport network an opportunity to recover lostpackets.

1. In a transport network having a set of edge nodes to which requestingend users are directed to obtain a live data stream, the methodcomprising: forwarding a given portion of the live stream from a firstnode to a second node in the transport network at a rate that is higherthan an encoded bitrate of the live stream; and after the given portionof the live stream is forwarded from the first node to the second node,forwarding a second portion of the live stream from the first node tothe second node at the encoded bitrate of the live stream; wherein thefirst node and the second node are each distinct from a node from whicha requesting end user initiates a request for the live stream, andwherein the given portion represents an amount of the live stream storedat the first node during a given time period; wherein, after issuing therequest, and as the second node waits for the given portion, having thesecond node ignore portions of the live stream other than the givenportion, where the second node ignores the portions of the live streamother than the given portion until data associated with the givenportion begins to be received or expiration of a time period duringwhich the data associated with the given portion has not begun to bereceived.
 2. The method as described in claim 1 wherein the transportnetwork is part of a content delivery network (CDN).
 3. The method asdescribed in claim 1 wherein the given portion of the live stream isconfigurable.
 4. The method as described in claim 1 further includingthe step of having the first node store a given portion of a second livestream, wherein the given portion of the second live stream is availableto be forwarded from the first node to a requesting node on an as-neededbasis.
 5. The method as described in claim 1 wherein the rate at whichthe given portion is forwarded from the first node to the second node isa given multiple of the encoded bitrate of the live stream.
 6. Themethod as described in claim 5 wherein the rate is configurable.
 7. Themethod as described in claim 1 wherein the first node is selected from aset of nodes that include an entry point, a reflector node, and an edgeserver node.
 8. The method as described in claim 1 wherein the secondnode is selected from a set of nodes that include a reflector node, andan edge server node.
 9. The method as described in claim 1 wherein thegiven portion of the live stream is stored in the first node as thegiven portion of the live stream passes through the first node.
 10. Themethod as described in claim 1 wherein the request to the first node isa subscription request.